home *** CD-ROM | disk | FTP | other *** search
-
- >(1) Has anyone done work wrt adding real data (in whatever format) to
- > www?
-
- No, but I think there's some stuff on gopher and WAIS servers that
- you might be able to get at.
-
- >(2) Is there a consensus on supporting MIME in HTML and vice versa?
-
- There's a growing consensus.
-
- The strategy isn't to shoehorn MIME inside HTML, though we are
- shoehorning HTML inside MIME, i.e. there will soon be a text/html
- MIME content type.
-
- The strategy is to treat the current data format as a special case of
- the more general MIME body part scheme. Currently, www clients expect
- text/html or text/plain body parts, and it uses things like filename
- suffixes to tell the difference. If you point www at
-
- ftp://ftp.ora.com/pub/davenport/Xhelp/Xhelp_Sept_11.ps
-
- It will gladly fill your screen with unintelligible postscript code.
-
- The strategy is that WWW clients will be able to negotiate various
- formats with servers, and the client will know what format the
- data is in before it comes over the wire. The other MIME types
- will be alternatives to text/html, not enclosures within it.
-
- For protocols like FTP, we need to have type information in
- the links, like:
-
- <a HREF="ftp://info.cern.ch/pub/www/NextBrowser.tiff"
- type="image/x-tiff">The NeXT browser in action</a>
-
- the the client would know better than to try to display the
- contents of the tiff file in a text window. The easiest thing
- to do is to pass it off to
-
- % metamail -b -c "image/x-tiff" /tmp/www_ftp.4322
-
- and let metamail to the rest.
-
- For WAIS, the type information is in the protocol. For gopher, it
- mostly is. For HTTP, the client and the server are supposed to
- negotiate the format based on compute resources required for the
- conversion, network transmission time, distortion/loss of data,
- etc.
-
- That's my two cents, anyway.
-
- Dan
-
-
-